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<n  Ada  oriented  framework  for  the  design  and  documentation  of  the  U.  S.  Army  TYC-39  store 
and  forward  message  switch  (military  software)  system  is  presented.  This  document  package 
contains  a  Requirements,  Design,  Ada  Integrated  Methodology,  and  Final  Report  section.  A 
methodology  to  use  Ada  in  specifying  requirements,  design,  and  the  Implementation  of  a 
system  was  developed.  This  methodology  was  used  to  redesign  the  TYC-39  message  switch 
system.  A  selected  software  module  was  programmed  after  the  redesign. 
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The  Ida  Capability  Study  was  performed  by  the  Data  Systeas 
Division  (DSD) ,  of  General  Dynamics  Corporation,  under 
contract  with  the  Departaent  of  the  Aray  Communications  - 
Electronics  Coaaand  (C2C0H) .  The  purpose  of  this  contract 
was  to  provide  a  docuaented  case  study  and  analysis  of  the 
use  of  Ada  in  the  design,  development,  and  iapleaentation  of 
a  large  scale  digital  systea. 

As  stated  in  the  Ada  Capability  Study  Dork  Plan,  this  task 
involved  the  perforaance  of  four  subtasks:  (1)  develop  a 
aethodology  for  the  use  of  Ada  in  the  specification  of 
reguireaents,  the  design,  and  the  iapleaentation  of  a  digital 
systea;  (2)  train  personnel  in  the  use  of  the  Ada  language 
and  the  aethodology;  (3)  use  the  developed  aethodology  to 
design  a  systea  for  the  AH/TTC-39  aessage  switch;  and  (4) 
prograa  one  selected  aodule  of  the  designed  systea. 

These  tasks  have  been  perforaed.  The  Ada  Integrated 
Methodology  (AIM)  was  developed  and  is  provided  as  one  of  the 
docuaents  produced  during  this  study.  AIM  includes  a 
reguireaents  aethodology,  a  design  aethodology,  and 
prograaaing  standards.  AIM  has  proved  to  be  an  effective 
aethodology  for  the  perforaance  of  this  Ada  Capability  Study. 
The  scope  and  applicability  of  AIM  has  liaitations  which  are 
detailed  in  the  AIM  docuaent.  It  is  not  presented  as  a 
general  purpose  aethodology. 

The  training  of  personnel  was  accoaplished  and  a  computer 
assisted  instruction  seguence  was  developed.  Section  4  of 
this  report  provides  details. 

Using  the  Beguireaents  Methodology  of  AIM,  an  Ada  Capability 
Study  Beguireaents  Docuaent  was  produced  which  states  the 
AI/TYC-39  aessage  switch  reguireaents  in  an  Ada-coapatible 
format.  The  Design  Methodology  of  AIM  was  used  to  provide  a 
systea  level  design  for  the  entire  aessage  switch.  A  detail 
design,  including  hardware-software  partitioning,  was 
accoaplished  for  the  output  aessage  aodule.  Since  the 
purpose  of  this  contract  was  to  study  the  use  of  Ada,  the 
design  effort  was  liaited  in  scope,  and  issues  such  as 
hardware  producibility,  reliability,  packaging,  EMI,  EMC,  and 
survivability  were  not  addressed. 

The  output  aessage  module  was  coded  in  Ada.  This  code  was 
processed  through  the  Ada/Ed  interpreter-compiler  and  is 
included  in  the  Ada  Capability  Study  Prograa  Listing 
Docuaent. 


2.  UjBlisaWa-Jjfleaasais 

The  following  docuaents  have  been  produced  during  the  Ida 
Capability  Study  contract  effort,  and  are  included  as  a  part 
of  the  Final  Beport. 

Ida  Integrated  Betbodclogy,  dated  28  June  1982 

Ida  Capability  Study  Beguireaents  Docuaent, 

dated  9  February  1982,  rewised  7  June  1982 
Ida  Capability  Study  Design  Docuaent,  dated  29  June  1982 

Ada  Capability  Study  Prograa  Listing  Docuaent, 
dated  21  June  1982 
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Ada  Capability  Study  Mork  Flan  was  published  in  August,  1981. 
The  design  teas  lead  personnel  had  been  chosen,  but  the 
design  teas  staffing  was  incosplete.  It  was  understood  that 
the  success  of  the  contract  effort  depended  to  a  great  extent 
on  the  background  and  gualifications  of  the  persons  selected 
as  design  teas  aeabers.  The  project  sanagesent  therefore 
sought  people  with  appropriate  gualifications  and  assigned 
then  to  the  design  teas  as  they  becase  available  froa  other 
projects  within  the  corporation.  Highly  gualified 
consultants  were  also  used  to  support  the  design  teas  effort. 

A  total  of  seven  esployees  were  assigned  to  the  design  teas 
during  the  contract  effort,  with  a  aaxiaua  staff  of  six  at 
any  one  tine.  Two  of  the  people  have  Haster's  degrees  in 
coaputer  science;  five  have  Bachelor's  degrees,  three  in 
aathesatics  and  two  in  electrical  engineering.  The  leader  of 
the  design  teas  was  chosen  because  he  had  specific  experience 
in  cossunications  and  telephone  switching  systeas.  Other 
teas  aeabers  had  varied  backgrounds  which  included  real  tine 
systeas  prograaaing,  coapiler  developaent,  and  business  data 
processing.  Four  of  the  people  had  experience  in  asseably 
language  and  Fortran;  three  had  used  structured  higher  order 
languages  including  Pascal. 

The  two  consultants  who  supported  this  design  teas  effort 
have  PhD  degrees  and  are  on  the  faculty  at  North  Texas  State 
University.  They  worked  in  the  aethodology  developaent  phase 
of  the  Ada  Capability  Study  and  were  therefore  able  to  advise 
the  design  teaa  aeabers  in  the  application  of  the 
aethodology. 

Because  of  the  varied  backgrounds  of  the  design  teas  aeabers, 
different  levels  of  training  were  reguired  to  ensure  the 
gualification  of  each  person.  The  training  curriculua  is 
described  in  Section  4  of  this  report. 

Taken  as  a  group,  the  design  teas  aeabers  perforaed  with 
excellence  and  did  an  outstanding  job  in  applying  the 
developed  aethodology  to  establish  reguixeaents,  create  a 
design,  and  prograa  a  selected  aodule  using  the  Ada  language 
in  its  various  foras.  Of  the  seven  teaa  aeabers  chosen,  only 
one  experienced  undue  difficulty  in  applying  the  developed 
aethodology.  This  person,  who  had  aany  years  of  experience 
with  real  tine  asseably  language  systeas,  found  the  aethods 
used  to  be  incoapatible  with  his  experience  in  systea 
developaent  and  asked  to  be  assigned  to  another  project. 

A  willingness  to  accept  new  concepts  and  a  positive  attitude 
toward  Ada  sees  to  be  qualities  which  were  necessary  for 
successful  participation  in  the  design  teas  effort.  An 
attitude  which  reflects  these  qualities  seeas  to  be  far  aore 
iaportant  than  the  particular  educational  background  or 
experience  of  an  individual. 
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It  should  be  noted  that  the  design  teas  was  coaprised  of 
well-qualified  people  who  were  selected  foe  special 
assignaent  to  the  Ida  Capability  Study  and  who  were  highly 
aotivated  and  intensely  interested  in  the  success  of  the 
project.  This  should  be  considered  in  estiaating 
productivity  for  any  large-scale  Ida  systea  development, 
because  the  perforaance  level  of  a  randomly  selected  group  of 
coaputer  professionals  will  not  be  as  high. 
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4.1  Pygfgss 

The  training  of  personnel  and  the  development  of  a 
coordinated  and  docnaented  training  prograa  have  been 
integral  parts  of  the  Ida  Capability  Study.  Early  in  the 
prograa  the  project  aanageaent  sought  effective  Ida  training 
in  the  fora  of  books,  video  tapes,  short  courses,  and 
tutorials.  It  becaae  evident  that  the  availability  of 
training  aaterials  at  the  level  required  for  the  Ida 
Capability  Study  was  liaited,  and  that  it  was  necessary  to 
develop  a  training  curriculua  to  aeet  the  training 
requirements  of  the  project.  The  experience  with  project  in- 
house  training  was  capitalized  upon  to  produce  a  foraal  Ida 
course  in  self-instruction  foraat. 
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In-house  training  of  Ada  project  personnel  was  conducted  in 
two  phases.  The  first  phase  consisted  of  ten  2-  to  3-hour 
presentations  given  to  the  original  members  of  the  Ada 
project  teas  by  Professor  Charles  Hansons,  a  project 
consultant  fron  North  Texas  State  University  (NTSU) .  These 
presentations  were  given  in  sesinar  fashion,  in  the  fora  of 
lectures  with  accoapanying  viewgraphs  and  handouts,  and  with 
free  class  discussion.  All  features  of  the  Ada  language  were 
covered  in  this  phase.  Because  of  tine  constraints,  nost 
topics  were  covered  rather  quickly. 

The  second  phase  consisted  of  a  reprise  of  the  first  phase 
given  primarily  for  new  teaa  aeabers,  but  open  to  anyone  on 
the  Ada  project.  These  sessions,  also  conducted  by  Professor 
Haaaons,  covered  fundanentals  of  the  language  in  nore  detail 
(in  seven  2-hour  meetings) .  Attendees  in  this  phase  had,  on 
average,  less  broad  experience  in  higher  order  languages  than 
those  in  the  first  phase,  special  eaphasis  was  given  to 
overall  program  structure,  data  types,  packaging,  and 
tasking.  Phase  I  experience  was  useful  in  identifying  and 
anticipating  student  difficulties. 

All  materials  used  in  the  training  activity  will  be  delivered 
at  the  end  of  the  contract  period  in  a  separate  document. 

An  important  activity  in  the  training  section  was  the 
formulation  and  analysis  of  training  issues  and  training 
requirements.  A  related  activity  was  the  evaluation  of 
available  training  materials. 

A  major  effort  in  the  training  section  was  the  development  of 
a  formal  Ada  course  in  coaputer-assisted-instruction  (CAI) 
format  and  its  implementation  on  an  Apple  II  personal 
computer.  This  self-instructional  course  can  be  used  by 
engineering  or  programming  department  personnel  on-site  or  on 
personal  equipment.  It  uses  a  coursewriting  tool  written  by 
our  NTSU  consultants  independently  of  this  contract. 

A  hardcopy  version  of  the  CAI  material  will  be  delivered  at 
the  end  of  the  contract  period. 


4.3  i£aiaiasJL§§a§§ 


A  major  issue  in  curriculum  development  is  the  question  of 
subsetting  the  language  for  training  purposes.  The 
experience  of  the  Phase  I  course  showed  that  thorough 
coverage  of  the  language  in  a  short  time  was  predictably 
confusing  to  students  less  experienced  in  higher-order 
languages. 

There  are  several  approaches  to  subsetting  into  a  core 
course.  Often,  such  approaches  assume  an  academic  context 
within  which  not  only  Ada,  but  basic  programming  concepts  are 
taught.  This  project  has  assumed  that  in-house  training  will 
be  to  professionals,  and  that  even  entry-level  personnel  will 
have  the  fundamentals  of  programming  and  data  structures. 
Approaches  to  a  core  course  include  the  following: 

Omit  certain  topics  entirely  in  the  core;  for  example, 
separate  out  system  programming  concepts  such  as  tasking 
and  reserve  for  advanced  or  specialized  courses. 

Problem:  in  training  for  embedded  systems  programmers, 
it  will  be  difficult  to  justify  omitting  "system" 
programming  features. 

Simplify  the  language  by  ignoring  certain  features  and 
options.  Problem:  it  is  desirable  to  cover  all 
features  designed  to  support  maintainability  and 
portability. 

Introduce  features  within  a  nested  sequence  of 
sublanguages.  Problem:  while  this  approach  is  suited 
to  the  academic  environment,  for  in-house  short  courses 
it  loses  its  designed  effect,  since  the  most  complex 
version  of  language  definition  is  given  shortly  after 
the  simplest. 
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The  iapleaentation  of  a  formal  Ada  course  for  individual 
self- instruction  on  a  personal  computer  is  an  original 
contribution  to  the  available  body  of  Ada  training  Materials. 
Several  features  of  the  development  tool  contribute  to  the 
flexibility  and  Modifiability  of  the  course  sequence. 

It  was  realized  early  in  the  project  that  effective  course 
Materials  aust  reflect  a  "systems  approach"  to  the  language. 
This  aeans  that  presentation  of  language  features  Must  be 
integrated  with  a  view  of  the  systea  life  cycle,  and 
accordingly  aust  be  related  to  prograa  design  Methodologies, 
language  support  issues,  and  project  aanageaent  tools.  The 
foraal  coarse  attenpts  to  achieve  this  integration  to  at 
least  the  ainiaua  extent  necessary  to  Make  the  Material 
appropriate  to  a  variety  of  potential  users. 

Project  experience  in  developaent  and  application  of  an  Ada 
Methodology  provided  a  unique  practical  perspective  from 
which  to  fornulate  a  systeas  viewpoint.  Further,  project 
experience  in  coding  a  complex  systea  function  provided 
insight  into  the  training  requireaents  to  support  such  a 
viewpoint,  and  into  design,  prograa  aanageaent  and  coding 
probleas  that  could  be  addressed  in  foraal  training. 


4.5  Conclusions 

T t  is  difficult  to  establish  a  single  Ida  course  to  satisfy 
the  needs  of  industry  personnel  requiring  varying  levels  of 
knowledge  of  the  language.  Short  courses  in  seainar  fora 
plus  a  self-instructional  or  prograsaed  learning  sequence  is 
suggested  as  an  effective  coabination. 

The  aost  experienced  prograaaers  and  analysts  can  profit  froa 
an  intensive  course  covering  the  entire  language.  Our  Phase 
I  experience  suggests  that  it  is  desirable  to  have  a  separate 
class  for  this  type  of  student  in  which  potential  advantages 
and  risks  of  the  language  can  be  explored  in  soae  depth. 

Language  training  will  appropriately  take  place  in  the 
context  of  modern  requirements,  design,  and  development 
methodologies  and  of  the  role  of  program  management. 

Grasping  the  design  of  the  language  requires  a  perception  of 
how  it  supports  development  and  maintenance,  and  of  bow 
complexity,  portability,  and  maintainability  are  managed  by 
production  standards.  These  issues  are  especially  pertinent 
to  the  training  needs  of  program  managers  and  system 
designers. 

On  the  state  of  language  definition:  Ida  instruction  must, 
in  the  short  tern,  take  account  of  open  implementation  and 
language  support  questions.  These  involve  significant 
performance  issues  such  as  real  time  requirements  and  run 
tine  support  provided  by  the  Ida  system.  Students  want  a 
clear  distinction  between  what  is  under  programmer  control 
and  what  is  the  responsibility  of  the  system. 

Class  response  as  well  as  coding  experience  on  the  project 
has  provided  insight  into  some  special  training  issues.  Beal 
time,  embedded  systems  programmers  need  to  be  shown  that  Ida 
will  support  familiar  concepts  such  as  interrupt  processing, 
priority  scheduling,  critical  timing,  background/foreground 
processing,  common  data  pools,  and  programmer  control  of 
execution  sequence.  Negative  transfer  from  other  languages 
is  likely.  Some  types  of  lexical  errors  tended  to  persist  in 
the  coding,  for  example,  failing  to  specify  a  discrete  range 
in  constrained  array  declarations. 
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5.  2S3iSfl-IS3JJ§5 
5.1  sisssiss 

The  discussion  in  this  section  is  the  result  of  the  process 
of  designing  the  TYC-39  nessage  switch.  Included  are  various 
findings,  problems,  deficiencies,  high  points,  history,  and 
personal  feelings  relating  to  this  contract.  In  addition, 
the  information  gained  from  the  various  action  requests 
during  the  project  have  been  incorporated  into  this  material. 
The  actual  message  switch  design  is  contained  in  documents 
accompanying  this  report,  referenced  in  paragraph  2 
(Applicable  Documents) . 
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5.2  £££l9fi_££0£es£ 

5.2.1  H^gaj^gagpts.fhgse 

The  aessage  switch  reguireaents  study  began  in  late  July  1981 
with  a  teaa  of  reguireaents  analysts  coaposed  of  the  chief 
engineer,  chief  prograaaer,  and  one  assistant  who  soon  becaae 
a  aeaber  of  the  aethodology  teaa.  1  lar^j  part  of  the  early 
effort  was  spent  perusing  the  "A  level"  and  "B5  level” 
specifications  and  soae  related  docuaents,  naaely  the  iutodin 
network,  JANAP-128,  ACP-127,  and  data  adapter  specifications. 
In  addition,  tiae  was  spent  researching  aanual  aethcds  of 
representing  and  restructuring  the  data  gleaned  froa  these 
specifications. 

On  August  4,  1981,  the  kickoff  meeting  was  held  for  the 
representatives  of  the  aray  at  Port  North,  and  the  initial 
plans  were  revealed.  During  this  aeeting,  a  basic 
understanding  of  the  aessage  switch  was  deaonstrated  by  the 
chief  engineer.  As  is  often  the  case,  plans  for  various 
personnel  were  changed  and  several  reassignaents  occurred.  A 
new  chief  aethodology  engineer  was  appointed,  one  of  the 
reguireaents  analysts  was  switched  to  the  aethodology  teaa, 
and  three  talented  consultants  froa  North  Texas  State 
University  were  added. 

The  chief  engineer  and  chief  prograaaer  reaained  on  the 
reguireaents  teaa  and  one  new  reguireaents  analyst  was  added. 
After  review  of  various  aethods  of  representing  reguireaents, 
the  SofTech  SADT  approach  was  selected  because  of  its  ability 
to  separate  data  and  control,  two  iaportant  components  of 
real  tiae  systeas. 

A  trip  to  Fort  Nonaouth,  NJ,  was  aade  in  early  October  by  the 
chief  engineer,  at  which  tiae  the  initial  SADT  diagraas  were 
presented  to  the  aray.  After  a  day-long  discussion,  soae 
siaplification  of  the  overall  task  was  agreed  upon,  and  a 
better  understanding  of  the  aessage  switch  battlefield 
applications  was  obtained.  There  were  soae  ainor  changes 
aade  to  the  SADT  diagraas,  but  the  initial  understanding  was 
on  the  right  track.  Ordinarily,  there  would  be  freguent 
aeetings  with  the  custoaer  to  resolve  aisunderstandings  and 
incongruities  in  the  specifications;  however,  the  message  • 
switch  application  is  a  standard  part  of  the  aray  eguipaent 
inventory  and  the  reguireaents  are  essentially  static.  For 
the  purposes  of  this  contract,  any  conflicts  between  wording 
of  specifications  was  evaluated  in  the  reguireaents  group  and 
the  most  practical  approach  was  taken.  This  undoubtedly 
expedited  the  reguireaents  phase. 

By  late  October  the  fiist  draft  of  the  Ada  acquirements 
aethodology  (ABN)  was  released  froa  the  aethodology  group. 
Fortunately,  the  data  flow  diagraas  were  still  based  on  SADT, 
but  additional  enhancements  were  supplied  by  structured 
analysis  technigues.  Soae  redrawing  of  the  diagraas  was 
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required  as  a  result  of  the  methodology  arrival  and 
additional  levels  of  deccaposition  occurred.  Another 
requireaents  analyst  was  then  assigned  to  the  project.  The 
chief  engineer  assigned  the  analyst  to  the  output  message 
section.  The  chief  prograaaer  was  continuing  with  aessage 
routing  and  the  previously-assigned  analyst  continued  on  the 
input  aessage  section.  Initial  assignaents  were  aade  by  the 
chief  engineer  based  on  individual  interest,  which  was 
soaewhat  related  to  their  backgrounds.  Hardware  types  worked 
in  areas  of  I/O  and  software  types  in  transform  analysis. 

The  chief  engineer  was  coordinating  the  requireaents 
development,  assisting  in  aessage  input,  and  spending  part  of 
his  time  completing  another  project  unrelated  to  the  message 
switch  (real  world  problem) . 

It  became  evident  that  the  requirements  analyst  assigned  to 
the  aessage  input  section  was  having  some  difficulty  in 
interpreting  the  specifications.  This  could  be  partly  due  to 
the  fact  that  the  i  level  specification  contained  two  pieces 
of  army  equipment,  only  one  of  which  was  applicable  to  the 
message  switch  contract.  Also,  a  great  amount  of 
implementation  detail  was  specified,  which  the  army  had 
verbally  indicated  we  should  ignore.  It  was  desired  that  the 
implementation  details  be  driven  by  the  design  process  (Ada 
oriented) ,  not  the  mapping  of  Ada  into  the  existing  design. 
These  considerations  added  a  degree  of  latitude  to  the 
process,  but  increased  the  difficulty  of  getting  to  the  pgaj 
requireaents.  Also  there  was  some  relunctance  on  the  part  of 
this  analyst  to  conform  to  ABH  (old  way  is  better). 

The  decomposition  process  continued  into  December  with  the 
development  of  a  data  dictionary  of  all  the  data  flows  on  the 
DFDs,  and  the  lowest  level  blacks  on  the  DFDs  were  expressed 
in  an  Ada  subset  as  much  as  possible.  Disciplined  English 
was  used  whenever  it  was  not  appropriate  to  use  Ada 
constructs  to  express  the  functional  requireaents. 

The  first  technical  interchange  meeting  was  held  at  Port 
Barth  in  mid-December.  At  this  meeting,  the  SofTecb  group 
(adjunct  contractor)  was  introduced  and  a  message  switch 
detailed  requireaents  discussion  ensued.  Initially,  it  was 
expected  that  the  design  document  would  be  completed  by 
Christmas,  but  this  was  not  accomplished.  The  aessage  input 
requireaents  were  considerably  behind,  and  the  requirements 
analyst  assigned  at  that  time  asked  to  be  removed  from  the 
project.  The  chief  engineer  and  chief  programmer  completed 
the  section  by  late  January  while  the  other  analyst  finished 
the  aessage  output.  Also,  in  January,  non-functicnal 
requireaents  were  completed,  concurrency  (high  level)  was 
studied,  and  a  concurrency  chart  was  produced. 

The  efforts  of  the  design  team  during  the  requirements  phase 
resulted  in  a  174-page  Ada  requireaents  document.  This 
document  restated  the  "A  level"  specifications  in  a  more 
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structured,  organized  forest  with  aany  sore  graphic 
illustrations  of  functions. 

The  application  of  ASH  produced  a  very  good  understanding  of 
the  problea  during  the  reguireaents  phase.  The  success  in 
this  area  can  be  aainly  attributed  to  the  functional 
decoaposition,  DFD  approach  used. 

5.2.2 

A  transition  froa  the  reguireaents  phase  to  the  design  phase 
took  place  in  late  January.  The  four  reguireaents  analysts 
continued  on  the  project  and  two  new  personnel  were  brought 
in  froa  engineering.  The  engineers  were  given  the  Ada 
reguireaents  specification  as  their  priaary  source  of 
inforaation  about  the  aessage  switch,  as  well  as  a  briefing 
on  the  aethodology.  The  design  teaa  set  as  a  group  for 
several  weeks,  scaetiaes  in  full  day  sessions.  Various 
issues  arose  during  the  sessions  and  the  need  for  individual 
thought  dictated  half  day  breaks  on  aany  occasions. 

The  first  two  weeks  were  spent  on  object-oriented  design. 
Since  none  of  the  designers  had  ever  participated  in  an 
object-oriented  design  session,  the  aethodology  group  was 
freguently  invited.  It  was  suggested  by  the  chief 
aethodology  engineer  that  the  search  for  objects  should  begin 
with  the  top  level  DFD  (node  AO) .  This  turned  out  to  be  a 
good  idea  since  four  out  of  seven  objects  appeared  at  that 
level.  The  process  of  identifying  operations  to  be  perforned 
on  the  objects  gave  the  design  teas  the  opportunity  to  sore 
closely  observe  the  relationships  between  data  structure 
coaponents.  Thus,  inforaation  hiding  tecbnigues  could  be 
applied  that  allowed  operations  to  be  hardware  independent. 
This  was  especially  evident  when  designing  the  "reference 
storage"  object,  where  the  "construct"  operation  was  defined 
to  sake  a  seguential  operation  work  acceptably  for  randon 
access  or  seguential  hardware  devices.  In  addition,  the 
"aessage"  data  structure  and  its  coaponents  provided  the 
basic  structure  for  the  systea  software  design  as  evidenced 
by  the  "aessage  scheaa"  presented  in  the  design  docuaent. 

Curing  the  design  sessions,  one  designer  was  in  charge  of 
updating  the  chalkboard  as  the  design  evolved.  The  chief 
engineer  refereed  the  discussions,  especially  when  it  was 
felt  that  enough  tine  had  been  spent  on  a  topic.  The 
chalkboard  was  copied  to  paper  by  the  participants  at  the  end 
of  each  design  session  or  when  a  new  topic  was  to  be 
considered. 

The  object-oriented  design  sessions  could  have  continued 
longer,  but  opinions  varied  as  to  what  additional  usefulness 
would  be  gained  froa  this  relatively  new  approach.  The  next 
step  in  the  aethodology  lasted  about  four  weeks  and  began  by 
utilizing  traditional  structured  design  technigues  to 
generate  a  structure  chart  of  the  aessage  switch.  Although 
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consideration  vas  given  to  startup/restart,  operator 
interface,  aaintenance  programs,  and  runtime  support,  the 
primary  design  emphasis  vas  related  to  message  processing. 
This  vas  because  the  message  processing  is  the  most  important 
real  time  aspect  of  the  system  and  all  other  softvare  in  the 
svitch  is  present  for  its  support.  The  support  functions 
vere  somevhat  limited  because  of  the  time  and  scope  of  the 
project.  The  emphasis  on  support  functions  vas  at  the 
interface  to  the  message  processing  function. 

In  mid-February  a  technical  interchange  meeting  vas  held  at 
SofTech  in  Boston.  It  this  meeting  the  chief  engineer  and 
the  designer  vho  had  been  transferred  from  the  methodology 
group  presented  the  results  of  the  requirements  phase, 
object-oriented  design  sessions,  and  part  of  the  structured 
design  sessions. 

The  structured  design  continued  after  the  interchange 
meeting.  Each  portion  of  the  message  processing  function  vas 
being  discussed  and  successively  refined.  The  tvo 
engineering  personnel  made  good  contributions  to  the 
sessions.  Betveen  the  requirements  document  and  group 
discussion,  they  obtained  an  excellent  understanding  of  the 
message  svitch. 

After  several  rounds  of  refinements,  the  chief  engineer  made 
assignments  to  team  personnel.  For  those  vho.  participated  in 
the  requirements  phase,  the  assignments  vere  in  a  different 
functional  area.  This  vas  not  only  to  provide  each  person 
vith  some  variety,  but  also  to  see  if  a  designer  could 
interpret  the  requirements  vritten  by  another  requirements 
analyst.  From  the  time  the  assignments  vere  made,  the  person 
responsible  for  a  particular  area  of  the  message  svitch  vould 
be  the  resident  "expert"  during  a  design  session  involving 
that  area.  This  helped  to  ensure  that  a  specific  designer 
vas  responsible  for  issues  arising  during  the  sessions 
pertaining  to  his  area  of  expertise,  and  part  of  his  time 
outside  the  sessions  vas  to  be  utilized  solving  these 
problems. 

Throughout  February  and  Barch,  the  structure  charts  vere 
refined,  concurrency  requirements  vere  identified  and 
coupling  and  cohesion  ("goodness"  of  design)  vere  evaluated. 
In  aid-Harch,  an  in-house  preliminary  design  reviev  vas  held. 
All  design  and  methodology  team  members  vere  present  as  veil 
as  an  army  representative  and  consultants.  An  overviev  of 
the  message  svitch  vas  presented  for  the  benefit  of  the 
consultants.  Then  the  object-oriented  design,  structure 
charts,  and  concurrency  vere  discussed.  Some  minor  errors 
vere  detected  during  the  process  and  it  vas  generally  agreed 
that  the  reviev  vas  vorthvhile. 

In  late  Barch  three  areas  of  the  message  svitch  vere 
identified  as  potential  candidates  for  coding  as  required  by 
the  contract.  Bessage  output  vas  suggested  as  the  number  one 
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choice  and  the  any  subsequently  agreed  at  the  aid-April 
technical  interchange  fleeting.  Also  in  late  harch  three 
design  teaa  aeabers  aade  a  presentation  regarding  the  nature 
of  this  contract  and  the  progress  lade  to  that  tine  at  an 
AdaTBC  fleeting  in  Salt  Lake  City,  Otah. 

In  early  April  interconnectivity  charts  were  aade  by  each 
designer  for  his  area  of  responsibility.  The  two  priaary 
data  structures,  linetable  and  routing  indicators,  were 
foraally  organized  and  recorded.  One  designer  with  auch 
hardware  experience  wrote  a  description  of  the  "run  switch" 
aodule  in  narrative  fora.  This  was  done  to  show  that  an 
effort  had  been  aade  to  do  a  ccaplete  systea  design.  The 
area  of  user  interface,  startup/restart,  fault  detection,  and 
aaintenance  diagnostics  are  just  as  iaportant  to  the  systea 
as  the  application.  Due  to  the  size  of  the  aessage  switch 
and  the  scope  of  the  project,  the  level  of  detail  in  these 
areas  was  necessarily  liaited.  The  first  seven  steps  of  the 
design  aethodology  were  coaplete  and  a  one  hundred  page 
docuaent  was  coapiled  for  the  critical  design  review  held  in 
aid-April. 

All  steps  in  the  aethodology  were  useful  for  design  purposes 
except  the  interconnectivity  charts,  which  were  intended  for 
docuaentation  of  interfaces.  The  inforaation  in  these  charts 
was  derived  directly  froa  the  structure  charts.  The  CEB  was 
then  held  at  the  SofTech  office  in  New  Jersey. 

After  the  COB,  the  Ada  unit  specifications  for  each  Ada 
design  unit  of  the  structure  chart  were  created  (step  nine  of 
the  design  aethodology) .  The  designers  accoaplished  this 
aostly  as  an  individual  effort,  with  reviews  by  the  chief 
prograaaer. 

The  hardware/software  partitioning  was  done  concurrently  with 
the  unit  specifications.  The  designer  who  wrote  the  "run 
switch"  description  worked  on  partitioning  full  tiae.  The 
chief  engineer  assisted  with  this  process  on  a  part-tiae 
basis.  In  addition  to  task  coordination,  tiae  was  spent 
assisting  with  the  data  structure  unit  specs.  It  was 
discovered  that  the  distributed  processing  approach  decided 
upon  by  the  hardware  designer  could  have  significant  iapact 
on  the  structure  that  had  been  defined  up. to  this  point.  ..The 
level  of  iapact  depended  on  where  the  partition  was  drawn.  A 
group  aeeting  was  called  to  discuss  the  Batter,  which 
resulted  in  a  partitioning  that  had  a  ainiaal  design  iapact, 
yet  provided  good  interprocessor  load  sharing  and  cost 
effectiveness.  The  conclusion  drawn  froa  the  experience  was 
that  the  hardware/software  partitioning  should  be  considered 
earlier,  particularly  in  a  distributed  environaent. 

Because  of  the  scope  of  the  project,  the  detailed  design  was 
done  only  on  the  selected  aodule  and  its  interfaces.  This 
included  the  aessage  output  section,  part  of  queueing 
(because  of  the  pre-eapt  reguireaent) ,  logging  history. 
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operator  aalfunctioo  notification,  bottoa  level  support  for 
■essage  aanipnlation  and  validation,  and  the  user  interface 
relating  to  system  dryup,  startup,  and  shutdown.  As  the 
detailed  design  phase  began  in  aid-April,  the  first  nine 
steps  of  the  Ada  design  aethodology  were  complete  and  the 
tenth  (H/S  partitioning)  was  in  process. 

The  detailed  design  phase  was  carried  out  differently  than 
recoaaended  by  the  Ada  design  aethodology,  partly  because  the 
expression  of  the  systea  design  in  Ada  PDL  would  not  be  very 
different  froa  the  reguireaents  BSL  that  already  existed, 
except  in  the  area  of  aessage  processing  support  routines.  A 
two  day  group  aeeting  was  held  to  establish  the  exact 
routines  and  functions  needed  for  this  support,  including  the 
aeaory  allocation/deallocation  scheae  for  aessage  buffering. 
After  establishaent  of  this  structure,  each 
designer/prograaaer  was  to  use  these  support  routines  as 
necessary  and  report  to  the  chief  prograaaer  any  new  support 
needed  but  not  yet  defined.  All  routines  in  the  HESSAGE.OPS, 
SIGflEHT_OPS ,  and  HAHAGE_IHTBAtlslT  packages  resulted  froa 
these  sessions,  as  well  as  the  aessage  scheaa,  a  diagraa 
showing  the  basic  internal  aessage  structure.  Having  these 
packages  at  the  start  of  the  detail  design  provided  a  certain 
aaount  of  consistency  to  the  resulting  design  because  each 
designer  worked  with  the  saae  building  blocks,  not  creating 
individual  special  purpose  routines  that  partially  duplicate 
functions.  This  approach  worked  extreaely  well.  Two 
designers  were  paired  to  design  the  output  aessage  validation 
routines,  another  defined  the  queueing  to  output  port 
interface,  another  designed  the  output  port  task  call/accept 
structure  and  support  routines,  and  another  continued  on 
hardware/software  partitioning. 

The  final  design  review  called  for  in  the  aethodology  was 
held  at  the  technical  interchange  aeeting  of  Hay  25  and  26 
near  Pt.  Honaouth,  H.J.  Essentially,  there  was  a  complete 
design  walk  through  (inforaally  held  at  General  Dynamics  the 
week  before),  a  design  philosophy  review  and  explanation  of 
the  hardware/sof tware  partitioning.  The  requirements- to- 
design  traceability  had  been  ccapleted  at  the  prior  design 
review  aeeting.  Although  there  was  no  foraal  preprogramming 
Ada  evaluation,  a  set  of  standards  was  developed  as 
prograaaing  progressed,  and  groups  consulted  with  each  other 
on  a  regular  basis  to  ensure  that  the  developaent  stayed  on 
the  right  track.  Since  nc  cne  had  any  Ada  programming 
experience,  the  AdaEd  coapiler  was  used  frequently  to  find 
syntax  and  coapiler  errors.  This  was  a  valuable  tool,  even 
though  it  was  soaewhat  difficult  to  use  (because  of  the  VAX 
resources  required) . 

Host  of  the  aessage  switch  support  routines,  queueing 
interface  and  validation  routines  had  been  written  by  the 
late-Hay  technical  interchange  aeeting.  The  "send  aessage" 
routines,  which  required  a  auch  closer  orientation  to  the 
hardware,  were  written  in  June.  It  was  quickly  determined 
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that  ida  has  soae  deficiencies  when  interfacing  at  the 
hardware  level.  These  are  described  in  other  paragraphs  of 
this  report.  Also  in  June,  tiae  was  spent  foraalizing 
various  docuaentation,  including  this  report. 

The  conclusion  up  to  this  point  is  that  aost  of  the 
constructs  needed  to  do  a  real  tiae  systea  developaent  are. 
available  in  Ada,  but  require  very  careful  study  to  use 
correctly.  The  teaa  aeabers  who  did  Ada  prograaaing  becaae 
very  proficient  in  its  use,  partly  with  help  froa  other 
prograaaers  and  partly  through  use  of  AdaEd.  The  reaaining 
question  at  this  tiae  is  whether  or  not  the  final  coapiled 
code  can  run  fast  enough  to  actually  control  a  aessage 
switch.  Hopefully,  this  will  be  deterained  in  the  near 
future. 
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Daring  the  design  phase,  a  potential  conflict  arose  several 
tines  between  reliability  and  aaintainability.  An  example  is 
in  the  output  aessage  section  where  there  is  a  reguireaent  to 
validate  certain  header  inforaation  that  was  previously 
validated  during  aessage  input.  Since  certain  code  would  be 
identical,  there  is  good  reason  to  create  a  package 
containing  this  shared  code  that  would  be  called  froa  both 
sections  of  aessage  processing,  cne  member  of  the  group  was 
concerned  that  this  approach  violated  the  reliability 
reguireaents  because  any  validation  error  not  detected  by  the 
routine  in  input  would  likely  not  detect  the  saae  error  in 
the  output.  Bis  suggestion  was  to  have  two  separately 
designed  (and  aaintained)  sets  of  code,  one  each  embodied  in 
the  input  and  output  sections.  This  creates  not  only  a 
aaintainability  problem,  but  in  all  liklihood  does  not 
enhance  reliability,  because  of  the  increase  in  coaplexity. 
This  designer  was  overruled  and  the  coanon  code  was  inserted 
in  a  single  package. 

5.3.  1.2 

One  issue  which  was  raised  during  the  project  was  the 
guestion  of  how  a  procedure  or  function  should  pass 
inforaation  back  to  the  invoking  routine  when  a  problem  is 
encountered.  The  classic  aethod  prior  to  Ada  has  been  to 
return  a  status.  This  usually  takes  the  fora  of  a  boolean  or 
an  enumeration  variable.  The  status  is  then  tested  and  the 
reguired  action  based  on  the  status  variable's  value  is 
perforaed.  The  alternative  provided  by  Ada  is  to  have  the 
called  routine  raise  a  programmer  defined  exception.  The 
invoking  routine  does  not  have  to  explicitly  test  the 
exception,  but  aust  provide  exception  handlers  at  the 
appropriate  place.  If  the  invoking  routine  wishes  to 
continue  with  soae  sort  of  processing  after  an  error,  then  a 
local  block  will  have  to  be  inserted  in  the  invoking 
procedure  to  hold  the  exception  handlers.  If  this  is  done, 
the  aaount  of  code  for  the  alternative  solutions  (using  or 
not  using  exceptions)  is  very  nearly  the  saae.  In  this  case, 
the  only  advantage  to  using  exceptions  is  that  a  function  may 
be  used  in  soae  places  where  a  procedure  would  be  needed  if 
explicit  status  was  being  returned.  For  further  discussion 
of  this  problem,  see  5. 5.4.3. 

5.3. 1.3  flgIg.ld3_lJJBl2J»gal2liga-IS^2Al-^22d2d 

In  several  areas,  the  designers  felt  that  knowledge  of  the 
operation  of  a  specific  Ada  iaplementation  would  be 
necessary.  One  of  these  areas  concerned  dynamic  allocation 
of  variables.  The  Ada  reference  manual  does  not  specify 
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whether  all  dynanic  variables  will  be  allocated  froa  a  coaaon 
pool,  or  froa  separate  pools  for  each  type  or  each  access 
type.  The  ability  to  specify  STCHAGE’SIZB  for  a  collection 
iaplies  the  latter.  This  knowledge  is  needed  if  the  designer 
is  to  control  aeaory  utilization  and  overflow  (as  is  required 
in  the  aessage  switch) . 

5.3.2  fiaa !  JCi 3S-S UBESIi 

5 . 3 . 2 . 1  id  a_ia§Jji  JSSi-Ii  3S_§J(steas 

is  ezpressed  at  several  technical  interchange  neetings,  there 
is  considerable  concern  over  the  nuaber  of  tasks  created  in  a 
complex  real  tiae  id a  environaent.  It  is  conceivable  that 
hundreds  of  tasks  will  be  reguired  in  the  aessage  switch  as 
designed,  ilthough  processor  units  exist  that  optiaize 
context  switching,  there  is  scae  doubt  that  the  overhead  can 
be  ainiaized  to  the  point  that  aessage  processing  (the 
application  progran)  will  not  be  adversely  affected. 

5. 3. 2.2  J2i5lliiilied_112fiSSsi2g_5a££ort 

ill  ida  support  provided  so  far  is  for  a  uniprocessor 
environaent.  it  the  tiae  of  hardware/software  partitioning 
it  was  deternined  that  a  distributed  processing  approach  was 
needed  to  handle  the  traffic  as  stated  in  the  i  level 
specification.  Unfortunately,  no  ida  docuaentaticn  exists 
that  explains  how  tasking,  procedure  calls,  and  access  types 
operate  in  a  distributed  processing  application.  The 
approach  taken  on  this  project  was  that  an  interprocessor 
coaaunications  handler  would  act  as  an  interpreter  in  each 
processor,  changing  intraprocessor  coaaands  to  a  fora 
suitable  to  intexprocessor  exchange  and  then  re-interpreted 
in  the  next  processor  in  the  scope  of  its  internal  structure 
(aeaory  layout,  resident  tasks,  etc.) .  There  are  potential 
probleas  with  this  approach  aainly  because  this  structure  is 
not  very  transportable  and  not  as  aaintainable  because  aore 
special  purpose  code  exists  than  there  would  be  i'f  this 
structure  were  supported  by  the  Ada  run  tiae  environaent.  It 
is  recoaaended  that,  as  soon  as  possible,  standard 
interprocessor  interface  packages  be  developed  to  work  in  the 
Ada  environaent.  For  exaaple,  one  serial  bus  interface 
standard  is  the  HIL-STD-1553E  bus.  A  transparent  Ada  run 
tiae  support  package  for  this  bus  should  be  developed  on  a 
priority  basis  if  real  tiae  distributed  eabedded  systeas  are 
to  be  successfully  developed  in  a  aaintainable  Banner. 

5. 3. 2.3  £jJ5ifia_Jjj£_Jia§_§3EE2£t 

There  is  a  concern  that  additional  run  tiae  support  will  not 
be  identified  until  late  in  the  systea  design  process,  thus 
causing  iapleaentaticn  delays  while  waiting  for  the  run  tine 
support  changes  to  be  iapleaented  and  tested  by  the  vendor. 

5.3.3  &&.j£2g]2ase 


■  ••] 

.1 


■] 
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5 . 3  .  3 . 1  5iSI5i_l3I  i  Jj!  ls_jj£^a  te 


The  generic  procedure  SHABED„VABIABLB_UPDATB  is  not 
sufficient  to  provide  the  functions  required  for  napped 
input/output.  The  problen  is  that  the  parameter  in  the 
procedure  is  of  node  "in  out".  In  this  node,  there  is  no  nay 
for  the  coapiler  to  deternine  whether  the  prograaner  intended 
a  call  to  SHABED_7ABIABLE_UE£ATE  as  a  store  or  as  a  load. 

The  designers  of  this  project  feel  that 

SHABED_7ABIABLE_0PEATB  should  he  replaced  by  two  generics, 
possibly  called"’sHAfiZD_>7ABIA£lB_STCBE  and 
SBABED_VABIAB1B_L0AD. 

5.3. 3. 2  Strings 

Type  string  is  defined  as  being  indexed  by  the  type  natural, 
which  does  not  allow  a  null  string,  while  null  arrays  nay  be 
defined.  If  a  record  is  constructed  which  contains  a  string 
and  character  count,  the  count  aust  be  of  a  type  other  than 
natural  if  no  characters  are  contained  in  the  string  (null) . 
Thus  a  conversion  aust  be  used  in  order  to  index  by  the 
count. 

5 . 3 . 3 . 3  t_£e£endeasisi_si.5sia£ 

Context  dependencies  can  beccae  rather  involved  for  separate 
subunits.  In  aany  instances  subunits  will  net  reguire  the 
context  of  the  parent,  nor  is  it  desirable  to  make  the 
subunit  available  on  a  global  basis  by  including  it  in  a 
library,  systeas  pregraaaers  and  aaintainers  would  benefit 
if  a  subunit  could  be  specified  as  "isolated".  The  ters 
"isolated"  in  this  instance  is  the  saae  as  "is  separate",  but 
without  inheriting  the  context  of  the  parent. 

s.3.4 

5.3.4. 1 

Conventions  and  standards  need  to  be  set  for  nailing.  All 
nases,  with  the  possible  exception  of  loop  indices  used  in 
very  saall  loops,  need  to  be  seaningful.  For  convenience, 
abbreviation  for  long  terns  nay  be  used,  but  if  they  are 
allowed,  they  should  be  standardized.  (For  a  sore  coaplete 
discussion  on  naaing,  see  SIGPLAN  notices  Vol.  17,  No.  5,  Bay 
1982  for  an  article  by  Breck  Carter  entitled  "Cn  Choosing 
Identifiers". ) 

A  special  naaing  problea  is  posed  by  tasks,  since  the  nane  of 
the  task  should  be  aeaningful  by  itself,  as  well  as  when 
coabined  with  the  naae  of  its  entries.  A  perfect  example  of 
how  not  to  naae  a  task  and  an  entry  is  provided  in  the  task 
FBEE.7EB,  whose  single  entry  is  FBES.VEBSICN.  When  a  call  is 
aade'to  this  entry,  the  call  reads  fIee_7BB.FHEE_VBBSI0N.  An 
exaaple  of  better  naaing  is  provided  by  the  task  DECOUPLE, 
whose  entry  is  LOG  for  a  call  of  DECOUPLE. LOG. 
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Coaaon  sense  naaing  nay  cause  problems.  For  example,  in  a 
package  with  a  set  of  operations  on  a  aessage  where  each 
routine  needs  a  aessage  as  a  paraaeter,  then  it  nakes  sense 
to  use  the  saae  paraaeter  naae  for  the  aessage  in  each 
routine.  Thus  given  the  following  procedures: 

procedure  BEAD_F BOH_PAHT 
(HESS&GZ  :  HSGID 

and 

procedure  FIHD  BI 

(HZSSAGE  :  HSGID  ;  ...  )  ; 

If  BBAD_FHOH_PABT  is  called  froa 
FIHD_HI  the  following  would  result: 

BEAD  FBOH  PAST  (  HZSSAGE  *> 

HZSSAGE  ,  ...  )  ; 

This  aay  not  be  a  problen;  however,  it  nay  look  strange  and 
potentially  confusing  to  the  novice  Ada  prograaaer. 

5. 3. 4.2 

A  standard  needs  to  be  set  for  the  use  of  the  DSZ  clause  (See 
the  coaaents  under  paragraph  S.6)  and  for  qualifying  nanes. 
Because  of  his  knowledge  of  the  systea  design,  the  original 
prograaaer  is  likely  to  use  naaes  without  gualification.  But 
the  aaintainer,  who  Bust  deteraine  the  origin  of  a  naae  in 
order  to  derive  its  aeaning,  nay  have  a  different 
perspective.  Hore  experience  with  Ada  aay  be  required  before 
a  reasonable  coaproaise  can  be  reached. 

?.  3 . 4 . 3  J£ilaiisn_sf_SAfcJUiil5 

There  is  need  for  a  standard  relating  to  the  use  of  separate 
coapilation  of  subunits.  It  is  a  convenience  to  the 
prograaaer  during  developaent  to  be  able  to  work  on  a  subunit 
in  a  saaller  file  which  is  not  being  accessed  by  other 
prograaaers.  Separate  coapilation  aay  also  be  useful  during 
debug  to  liait  the  size  of  recoapilations.  However,  separate 
coapilation  poses  a  problen  during  aaintenance,  since  a 
subunit  then  appears  "out  of  context".  One  solution  to  this 
problea  night  be  to  use  separate  coapilation  during 
development,  but  serge  the  separate  files  during  the  final 
stages  of  systea  integration. 

5 . 3 . 4 . 4  Hii.SSJJdiiiSDS 

It  is  possible  to  conditionally  exit  a  loop  in  Ada  with  two 
different  constructs.  The  first  is  the  "exit  when  condition" 
and  the  other  is  by  placing  an  unconditional  "exit"  statement 
in  an  if  statement.  To  aaintain  uniformity,  it  may  be  useful 
to  establish  a  standard  favoring  one  or  the  other  of  these 
forms.  Soae  of  the  prograiaers  on  this  project  felt  that  the 
"exit  when"  statement  was  insufficiently  prominent  in  order 
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to  visually  denote  its  importance  as  an  element  of  control. 
These  programmers  felt  that  using  an  if  statement,  with  the 
subsequent  change  in  indentation,  made  the  exit  more  visible. 
Of  course,  the  same  effect  could  be  obtained  by  setting  a 
special  standard  for  the  indentation  of  the  exit  statement. 

5. 3. 4. 5  Overloading 

Standards  must  be  set  for  overloading.  The  overloading  of 
enumeration  literals  can  be  very  confusing  and  should  be 
avoided.  Overloading  of  functions  and  procedures  should  be 
allowed  only  when  the  same  operation  or  action  is  being 
performed  by  the  overloaded  routines.  A/  even  more  strict 
approach  might  be  to  restrict  overloading  of  routines  to 
those  produced  by  instantiation  of  the  same  generic.  The 
cases  of  overloading  in  this  project  were  produced  in  this 
way.  Some  apparent  overloading  of  names  which  are  in 
different  scopes  should  be  expected  in  a  large  project,  and 
may  be  tolerated  if  the  scopes  are  sufficiently  separated  to 
remove  all  possibility  of  misunderstanding  by  a  aaintainer. 
Also,  the  hiding  of  names  is  an  outer  scope  by  names  declared 
in  an  inner  scope  is  to  be  strictly  avoided.  The  potential 
for  maintainer  confusion  in  such  cases  is  too  high. 

5. 3. 4. 6  G§S§I3l_S£3B3§£3s 

A  set  of  standards  was  developed  for  the  coding  phase  of  the 
project.  Some  Pascal  standards  were  modified  for  Ada  use  at 
the  start  of  coding  and  further  modified  as  the  project 
progressed.  See  the  AIH  document  Chapter  4  entitled  "Ada 
Development  Standards".  Some  of  the  items  listed  in  the 
standards  were  added  as  a  result  of  experience  in  the  coding 
phase,  thus  the  output  message  module  furnished  with  this 
report  does  not  reflect  all  the  standards. 

5 . 3 . 4 . 7  Allots  jog.  gQqrdwgre.agsgugggs 

Open  interfacing  to  a  hardware  integrated  circuit  (the  Intel 
8254)  ,  a  paradox  was  encountered.  The  8254  circuit  has  three 
independent  identical  counter/timer  channels.  Two  possible 
choices  are: 

a.  Define  the  utilization  and  mode  of  each  of  the  three 
channels  in  a  single  package,  or 

b.  Define  the  above  in  those  packages  in  which  a  channel 
(or  channels)  is  used. 

The  former  is  advantageous  since  the  hardware  utilization  is 
specified  in  one  place.  If  the  latter  method  is  used,  one 
cannot  easily  determine  what  portion  of  the  hardware  is 
already  allocated,  or  where  it  is  defined.  Cn  the  other 
hand,  defining  such  in  a  single  package  does  not  hide  those 
channels  from  those  compilation  units  that  use  only  a  portion 
of  the  resources. 
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5.4  lessons  learned 

Summaries  of  the  lessons  learned  from  the  Ada  Capability 
Study  are  provided  is  the  following  paragraphs. 

5.4.1  Importance  of  Using  a  Methodology 

Hethodologies  provide  a  plan  or  road  aap  for  system 
development.  Without  a  plan,  the  system  development  of  any 
major  system  is  more  susceptible  tc  failure.  A  methodology, 
even  though  it  may  only  be  a  framework  such  as  Aid,  forces 
the  project  team  personnel  to  think  about  the  problem  and 
solution  in  an  organized  manner.  In  the  words  of  one  of  our 
consultants,  "Any  methodology  is  ninety  percent  good". 

5.4.2  Importance  of  Understanding ^the^Probjgn 

It  is  extremely  important  tc  develop  an  understanding  of  the 
problem  in  the  requirements  phase  of  system  development. 

This  is  true  regardless  of  the  type  of  system  being  developed 
(i.e.,  business,  real  time,  scientific,  etc.).  Once  a  good 
understanding* of  the  problem  is  developed,  the  design  process 
is  ready  to  begin. 

The  design  team  used  much  more  time  and  effort  than 
originally  anticipated  to  complete  the  requirements  phase. 
However,  the  feeling  is  that  the  extra  time  was  well  spent. 
The  requirements  analysts  developed  an  understanding  of  the 
problem  that  reduced  the  effort  required  during  the  design 
phase. 

5.4.3  Dse  of  Ada  as  an  BSL  Seduces  Design  and  Programming 

The  Ada  Requirements  Specifications  produced  during  the 
requirements  phase  eliminated  the  need  for  an  Ada  PDL 
expression  of  the  system  during  the  design  process.  The 
design  team  felt  that  the  Ada  Requirements  Specifications 
were  sufficient  specifications  to  begin  program  development 
once  architectural  design  was  completed.  The  programming 
effort  was  also  reduced  because  the  frameworks  of  many  of  the 
Ada  procedures  were  established  during  the  requirements 
phase. 

5.4.4  Lack  of  Integration  Between  Structured  Analysis 

§M__5trjjstursd_£§sj2n”'" 

Structured  Analysis  and  Structured  Design  methodologies  do 
not  integrate  as  smoothly  from  requirements  to  design  for 
real  time  communications  systems  as  they  do  in  a  business 
applications  environment. 

5.4.5  Ada  Can  Be  Used  Throughout  the  System_DeveloEBient 

ilfs-sisli 
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Ada  has  the  constructs  for  forming  the  base  of  a  structured 
English  for  expressing  system  reguirements  and  programming 
specifications.  Therefore,  Ada  may  be  used  as  an  BSL  and  BEL 
prior  to  its  use  as  an  implementation  language.  The  use  of 
Ada  throughout  the  system  development  life  cycle  reduces  the 
conversion  efforts  normally  reguired  to  map  reguirements  into 
design  and  design  into  code. 


5.4.6  Ada  is_BOSt.  Cgmpptjfr^e., with_th$,01)  jectTOcjgntgd 
£esi32_Method2log2 

Ada  will  support  virtually  an;  methodology.  However,  it 
appears  that  Ada  is  aore  compatible  with  the  object-oriented 
design  methodology  than  ether  methodologies  such  as 
Structured  Design,  Jackson,  and  Sarnier-Orr. 

5.4.7  Ba£kj22und§_2i_!suornel_Bevelc2i2g_33a_3istsms 

i§_i5£2Itjnt 

Of  course,  it  is  always  iaportant  to  aatch  people  with 
appropriate  backgrounds  to  developaent  projects.  The  best 
prograaaer  is  not  always  the  best  reguireaents  analyst  or 
designer.  Therefore,  the  personnel  assigned  to  the 
reguireaents  and  design  phases  need  not  be  expert  Ada 
prograaaers.  However,  the  reguireaents  analysts  and 
designers  need  to  have  soae  knowledge  of  Ada. 

The  reguireaents  analysts  should  be  faniliar  with  the  basic 
Ada  constructs  if  Ada  is  used  as  an  BSL  during  the 
reguireaents  phase.  Designers  should  know  enough  about  Ada 
to  use  it  as  a  PDL.  Additionally,  designers  should  have  a 
good  understanding  of  Ada  prograa  structure  (i.e., 
subprograms  and  packages)  and  tasking. 

5.4.8  Heed  for  Hore  Customer-Oriented  Beguireaeqts 

Specifications  ~  ™  — — —  - 

ABU  is  heavily  oriented  toward  Structured  Analysis.  The  Ada 
language  is  also  key  to  ABB  since  it  is  used  to  express  the 
systea  reguireaents.  Therefore,  the  Ada  acquirements 
Document  is  largely  EFDs  and  Ada  Beguire'aents  Specifications. 
This  format  is  great  for  the  reguireaents  analysts  and 
designers.  However,  froa  a  customer's  point  of  view  the  Ada 
Beguireaents  Document  is  not  a  good,  clear  expression  of  the 
systea.  The  Structured  Analysis  and  Ada  expressions  of  the 
system  need  to  be  augmented  with  aore  customer-oriented 
systea  reguireaents. 

5.4.9  V3l]iS_2i_5£a£ii£_I21u§  tjjiia  ns 

DFDs  and  structure  charts  are  good  tools  that  facilitate 
developing  an  understanding  of  the  problem  and  solution 
during  the  reguireaents  and  design  phases  respectively. 
However,  the  use  of  such  tools  puts  Ada  in  a  more  supportive 
role  than  originally  anticipated.  The  graphic  illustrations 
seem  to  be  easier  to  understand  initially  than  a  pure  Ada 
expression  of  the  problem  and  solution. 

5.4.10  51X3SP3Pg-g&3£Pg-l£e_ng£_£gsiaBSi-lo.5aEPO£t^siu^on 

Structure  charts  have  been  used  prolificly  during  the  design 
of  systems  to  be  implemented  in  CCECL  or  FOBTBAN.  Since 
neither  of  these  languages  is  recursive,  there  is  no  need  for 
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representing  recursion  on  the  structure  chart.  The  lack  of  a 
structure  chart  recursion  sechanisa  aay  be  a  problea  when 
trying  to  aodel  an  Ada  solution  that  is  recursive. 

5.4.11  ISS£2>£i3£t§_2i5_B2i_iEE£2£I  0£ 

£22£§sentin3_tlie_Concijrre£Sy_2l_tj3S_Bessage_Jwii££_Si§ief 

The  design  teaa  was  unable  to  use  the  SHZH-type  concurrency 
charts  to  represent  the  concurrency  of  the  aessage  switch 
systea.  One  of  our  consultants  tried  extensively  to  draw  a 
concurrency  chart  for  the  aessage  switch  systea  but  was 
unsuccessful.  &  second  consultant  indicated  that  it  was 
iapossible  to  illustrate  the  concurrency  of  the  aessage 
switch  using  SREH-type  concurrency  charts. 

5.4. 12  Autoaated  Design  Ajds.ggul3.IijBSgys.$fre_SYSteB 
Develgpagjt. process 

Automated  design  aids  could  be  used  to  iaprove  project 
aanageaent,  increase  productivity,  and  iaprove  the  accuracy 
of  reguireaents  and  design  specifications.  Specifically, 
autoaated  design  aids  could  be  used  to  do  the  following: 

-  Draw  DFDs  and  structure  charts  initially  cr  from 

analyzing  ida  code 

-  Develop  traceability  aatrices 

-  Structure  reguireaents  and  design  specifications  for 

clarity 

-  Develop  a  data  dictionary 

-  Verify  reguireaents  and  design  specifications 

-  A  cross-reference  tool  to  list  the  location  of 

packages,  type  definitions,  variable  declarations, 

subprograa  and  task  specifications,  etc. 

-  Additional  cross  reference  tools. 


5. 5  Sfessivaiifi n§ 

5.5.1  ssjisaliasi  §I_£saasai  § 


The  use  of  Jackson  structure  diagraas  to  depict 
objects,  attributes  of  objects  and  operations  on 
objects  provided  a  conaon  coanunicational  tool  for 
the  project  personnel.  The  personnel  quickly 
becaae  fluent  Kith  this  notation  and  coaaunicated 
with  other  project  personnel  successfully  in  this 
environnent. 

is  one  night  expect,  differences  arose  as  to  which 
coaponents  of  the  systea  were  indeed  objects  and  to 
what  level  of  detail  these  objects  should  be 
aodeled.  These  differences  were  generally  resolved 
as  the  proponents  presented  argunents  for  their 
view  of  the  systea  and  were  required  to  support 
those  arguaents. 

The  initial  atteapt  at  object  developaent  was  based 
on  the  reguireaents  dccuaents.  This  initial 
atteapt  was  "reasonably  close"  to  the  final  version 
of  objects.  Thus,  the  iterative  process  of 
refining  those  initial  objects  was  not  protracted. 
That  initial  nodel  was  an  excellent  foundation  to 
work  from. 

Clearly,  scae  design  decisions  which  proaoted 
inforaation  hiding  evolved  froa  the  object  oriented 
approach.  The  operations  on  objects  becaae  aore 
clearly  defined  within  the  design  sessions  leading 
to  soae  general  operations,  thereby  increasing  the 
siaplicity  of  soae  objects. 

The  tine  spent  by  the  reguireaents  teaa  during  the 
requireaents  phase  definitely  facilitated  the 
design  process  at  all  steps  within  the  aethodology. 
However,  this  was  very  evident  during  the  object 
developaent  as  the  requireaents  teas  aeabers 
contributed  heavily  to  the  object-oriented  nodel. 

While  the  knowledge  gained  during  the  requireaents 
phase  was  fundanental  to  understanding  and 
constructing  the  object-oriented  design,  it  was 
felt  that  there  was  little  foraal  connection 
between  the  two  (e.g.,  traceability). 

Within  object-oriented  design,  concern  was 
expressed  over  specifying  how  the  objects 
interacted  with  one  another  (this  was  referred  to 
as  the  "glue"  which  tied  the  objects  together). 
Specifically  object-oriented  design  does  not 
specify  flow  of  control,  this  is  accomplished  using 
the  Ada  PD1. 
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-  Because  flow  of  control  is  not  specified  in  the 
objects,  concurrency  Has  not  indicated  (except 
through  the  replication  of  objects) . 

-  Special  difficulty  existed  in  representing  a 
■essage  object,  eostly  because  it  "migrated" 
through  the  other  objects,  changing  internal 
representation. 

The  fact  that  the  design  teas  Has  highly  trained 
and  had  experience  nith  real  tine  processing, 
seeaed  to  facilitate  the  use  of  all  aethcdologies. 

.5.2 

Very  fen  general-purpose  packages  Here  developed  in  the 
course  of  this  project.  These  are  packages  that  are 
suitable  for  use  in  a  library  of  such  packages;  i.e., 
they  are  "off  the  shelf  iteas.  The  availability  of 
such  packages  Hill  greatly  reduce  coding  tine  over  the 
course  of  several  projects.  However,  the  uriting  of 
these  packages  aay  take  additional  tiae  in  order  to 
vrite  the  necessary  extra  docuaentation  for  future  users 
of  such  packages. 
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5.6.1  SSMUl_IillSS3_2.f-afl_.B2i 


The  use  of  any  high  level  language  (versus  the  use  of 
asseably  language)  autoaatically  generates  benefits  in  two 
areas:  an  increase  in  the  speed  of  prograa  developaent,  and 
an  increase  in  prograa  readability  and  understandability . 
Studies  have  shown  that  the  rate  of  prograa  developaent 
(about  ten  lines  per  prograaaer  per  day)  is  largely 
independent  of  the  language  being  used.  Since  a  high  level 
language  generates  the  equivalent  of  aany  lines  of  assenbly 
language  for  each  line  of  BOL,  a  particular  prograa  function 
can  be  developed  in  considerably  less  tiae  with  the  BOL  than 
with  asseably  language.  In  addition,  the  use  of  an  BOL  frees 
the  prograaaer  froa  the  tedious  details  which  are  associated 
with  the  use  of  asseably  language,  and  the  aany  possible 
errors  for  which  its  use  creates  a  potential,  such  as  losing 
a  value  through  failure  to  store  it,  or  failing  to  save  the 
proper  registers  during  calls  or  interrupts.  The  readability 
of  a  prograa  in  an  HCL  is  enhanced  by  such  things  as 
aeaningful  naaes,  decision  constructs,  and  the  very  absence 
of  the  tedious  details  aentioned  above. 


5.6.2  £SflSUl_2i£US3-SX_l..§£UcUU£-I'3&SflflflS 

Structured  languages  have  two  aajor  benefits  for  prograa 
developaent  which  nonstructured  languages  (including 
nonstructured  HOLs)  lack.  The  first  benefit,  an  increase  in 
the  ease  of  prograa  design  and  an  increase  in  readability,  is 
generally  recognized,  and  will  not  be  discussed  further.  The 
second  benefit  is  the  fact  that  a  structured  language  can  be 
used  as  a  prograa  design  and  docuaentation  language  (PDL) . 
Using  the  saae  language  for  POL  and  for  coding  siaplities 
training  by  aaking  the  required  training  in  the  POL  siaply  a 
part  of  the  training  in  the  ceding  language.  In  addition, 
when  the  design  is  described  in  the  saae  language  as  the 
prograa  to  be  coded,  the  process  of  turning  a  design  into 
code  is  greatly  siaplified  and  will  proceed  auch  acre 
quickly. 

5.6.3 

5 . 6 . 3 . 1  SHSflfl_3j£i  AS 

The  fact  that  variables  of  two  different  types  nay  not  be 
aiied  in  an  expression  or  assigned  to  each  other  without  an 
explicit  conversion  helps  prevent  errors  in  coding,  although 
it  does  occasionally  add  apparent  coaplexity  to  an 
expression.  (No  real  coaplexity  is  added  by  an  explicit 

expression.  The  coaplexity  already  exists  -  the  conversion 
just  aakes  it  visible.) 

5. 6.  3.2  usJsiflfl 
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Ada's  tasking  capabilities  provide  an  excellent  way  to 
express  any  requirements  for  concurrency  which  the  design  aay 
possess.  The  abilities  to  have  task  types  and  to  dynamically 
allocate  new  tasks  as  required  can  add  flexibility  to  a 
design. 

5.6. 3.3  !3£jS3SiS2 

The  designers  of  this  project  found  four  criteria  for 
building  packages,  each  of  which  seeas  to  have  its  place: 
packaging  around  a  data  base,  packaging  by  aajor  prograa 
functional  area,  packaging  around  a  type  (or  an  object),  and 
packaging  for  general  purpose  hardware  support. 

Packaging  around  a  data  base  is  illustrated  in  this  project 
by  such  packages  as  BI_OPS  and  LISI_TBL_CPS.  By  placing 
inforaation  used  by  aany  aodules  in  a  package  and  restricting 
access  to  the  data  in  such  a  way  that  the  only  way  the  data 
can  be  read  or  written  is  through  the  functions  which  are 
also  contained  in  the  package,  the  integrity  of  the  data  aay 
be  acre  easily  ensured.  Haintenance  is  also  aade  easier  by 
the  fact  that  the  only  access  to  the  data  is  through  the 
routines  in  the  package. 

Packaging  by  najor  prograa  functional  area  is  illustrated  in 
this  project  by  such  packages  as  PHYSICA1.PCBT  and 
PBOCZSS_ HESS 1GB.  In  this  technique,  the  package  is  used  as  a 
container  for  the  routines  and  tasks  of  soae  najor  functional 
area  of  the  prograa,  along  with  the  types  and  variables 
required  for  their  interfaces.  The  technique  would  sees  to 
be  best  suited  to  projects  in  which  the  aajor  areas  of  the 
prograa  function  independently,  and  do  not  have  a  "driver" 
controlling  their  operations. 

Packaging  around  a  type  is  soaewhat  siailar  in  aotivation  to 
packaging  around  a  data  base,  in  that  access  to  objects  of 
the  type  aay  be  constrained  to  the  routines  provided  in  the 
package  by  the  use  of  private  and  liaited  private  types,  but 
the  objects  reside  outside  the  package.  SEGHENT.OPS  and 
HBSS1GB_0PS  are  exaaples  of  this  type  of  package. 

Curing  the  technical  sessions  the  Bray  representatives  have 
elaborated  on  the  need  for  "off  the  shelf"  packages  that  can 
be  inserted  as  a  particular  function  is  needed.  Cne  such 
package,  "Interface  to  8254",  is  a  general  purpose  timer 
package  developed  to  support  an  8254  LSI  interval  tiaer. 

Three  Ada  language  diff iciencies  aake  the  package  less 
universal  than  desired.  Cne  restriction  is  aore  cosaetic  in 
nature  and  is  discussed  in  paragraph  5. 6. 5.5.  Another 
relating  to  hardware  interfacing  probleas  is  discussed  in 
paragraph  5.6.5. 1  and  the  third  problea  relating  to  shared 
variable  update  is  discussed  in  paragraph  5.3.3. 1.  It  is 
fully  expected  that  these  probleas  will  recur  as  other 
hardware  interface  packages  are  developed. 
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5. 6. 3. 4  siisa-issiajiififlis 


Slice  assignments  are  a  einor  but  highly  appreciated 
convenience,  since  they  allow  the  prograeaer  to  accoaplish  in 
one  stateaent  what  would  require  a  loop  in  aost  languages. 

5 . 6 . 3 . 5  Separation_fll_Sjecilication_ajd  Body 

The  Ada  capability  for  separation  of  the  specification  and 
the  body  of  a  procedure  provided  two  benefits  for  the 
project.  The  first  benefit  was  that  it  allowed  the 
interfaces  between  aodules  to  be  written  independently  of  the 
bodies  of  the  nodules,  in  an  early  stage  of  the  development 
of  the  design.  This  was  especially  useful  in  the  case  of 
aodules  which  were  used  in  aore  than  one  case,  since  the 
specification  of  such  a  nodule  could  be  distributed  to  all 
the  prograaaers  who  were  writing  aodules  that  called  it,  so 
that  they  would  know  what  syntax  to  use  in  the  call.  A 
second  use  of  this  separation  capability  was  that  it 
prevented  circular  dependencies  fron  developing  between 
aodules. 

s .  6 . 3 . 6 

The  dynaaic  storage  allocation  capabilities  of  Ada  allowed 
the  designers  to  aake  good  use  of  storage  without  having  to 
divide  aeaory  into  fixed  portions  at  the  start.  In  order  to 
aake  full  use  of  this  capability,  however,  the  designers 
would  need  to  know  how  the  specific  Ada  iapleaentaticn  which 
they  are  using  accoaplishes  those  functions. 

5.  6. 3.7  fiysilflidiM 

Project  personnel  found  the  overloading  capabilities  of  Ada 
useful  when  used  for  naaing  subprograas  which  accoaplished 
the  saae  function  on  different  types.  The  specific  routines 
with  which  this  was  done  were  PBEE  and  GET.  There  are  three 
routines  by  each  of  these  naaes. 

5 . 6 . 3 . 8  Gentries 

The  prograa  designers  used  generics  to  develop  subprograas 
such  as  the  above  aentioned  ZEZE  and  GET;  the  individual 
versions  of  which  are  logically  the  saae. 

5-6. 3.9  JJLSISiaiifia-IIESS 

The  Ada  enumeration  type  is  very  useful,  and  aore  enumeration 
types  were  declared  in  this  project  than  any  other  user 
defined  type.  It  proved  to  be  extremely  useful  to  be  able  to 
refer  to  the  parts  of  a  message,  for  example,  as  HEADE3, 
HSG_BODY,  and  TBAILEB ,  rather  than  by  nuaber.  ether 
enumeration  types  were  used  to  represent  conditions  and  error 
codes. 
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5.6.3.10  SJStS&SU 


The  designers  found  it  quit«  useful  to  be  able  to  specify 
actions  to  be  taken  when  unanticipated  error  conditions 
arose.  Predefined  ids  exceptions  were  used  in  a  nunber  of 
places  to  handle  problees  which  could  have  been  explicitly 
checked  for  by  the  prograaaer,  and  in  at  least  one  place  an 
exception  was  raised  by  an  explicit  check.  Prograaaer 
defined  exceptions  were  not  utilized,  but  they  could  have 
been  used  to  pass  error  conditions  up  the  calling  tree. 

5.6.3.11  Becorfla 

The  Ida  record  type  proved  to  be  the  second  aost  coaaonly 
defined  type  in  this  project.  Becords  proved  to  be  valuable 
in  linked  lists  and  other  linked  data  structures,  as  well  as 
in  input/output  operations  and  as  paraaeters. 

5.6.3.12  &ais4..iasfi£ia£i£2 

ill  the  personnel  eaployed  in  design  and  coding  cn  this 
project  felt  that  the  use  of  naaed  association  in  procedure 
and  function  calls  and  in  record  aggregates  aade  the  code 
auch  aore  easily  understandable. 

5.6.4 

5.6.4. 1  Overloading 

The  iaproper  use  of  overloading  can  create  probleas  in  both 
design  and  aaintenance,  since  it  aay  be  difficult  for 
prograaaers  (both  the  original  coders  and  the  naintainers)  to 
deteraine  what  is  being  referred  tof  even  when  the  coapiler 
is  able  to  resolve  the  overloading  with  no  difficulty.  The 
designers  on  this  project  feel  that  overloading  should  be 
strictly  controlled,  and  in  the  case  of  subprograa 
overloading,  be  applied  only  to  those  subprograas  which 
accoaplish  the  saae  action  on  differing  types. 

5*6. 4. 2  Tasking 

The  Ida  tasking  feature  should  only  be  used  by  designers  who 
are  fully  conversant  with  the  dangers  of  concurrent'': 
processing.  One  very  distinct  possibility  raised  by  the  use 
of  tasking  is  that  of  deadlock,  also  known  as  deadly  eabrace. 
In  this  condition,  two  tasks  interact  in  such  a  way  that 
neither  task  can  proceed  without  soae  action  on  the  part  of 
the  other.  This  situation  could  be  difficult  to  detect  in 
soae  systeas,  since  all  the  other  tasks  in  the  systea  sight 
continue  to  operate  noraally. 

5. 6. 4. 3  Uss-Blians 

The  unrestrained  use  of  exceptions  to  handle  probleas  should 
be  avoided.  It  is  possible  for  a  routine  to  be  aborted 
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through  no  fault  of  its  own,  and  without  a  chance  to  "clean 
up"  any  of  its  actions.  For  exaeple,  if  routine  A  calls 
routine  B  which  calls  routine  C,  and  an  exception  is  raised 
in  C  which  is  not  handled  there,  it  is  possible  (especially 
if  the  person  who  wrote  B  did  not  know  that  C  could  raise 
this  particular  exception)  that  control  could  revert  to  A 
without  B  having  any  chance  to  undo  any  of  its  actions.  The 
use  of  "when  others"  in  the  exception  portion  of  a  routine 
also  has  its  problems,  the  sain  one  being  that  an  exception 
of  an  altogether  unexpected  type  lay  occur,  perhaps  being 
raised  by  soae  routine  which  the  current  routine  does  not 
directly  call. 

5.6.5 

5 . 6 . 5  .  1  JUSbiB§z3ES£ili£_.£l2S£3J«inS 

Although  the  Ada  facilities  for  machine-dependent  programing 
look  adequate  at  first  glance,  actual  use  reveals  severe 
deficiencies.  This  is  especially  probleiatical  in  eabedded 
systems,  where  such  aachine-dependent  programing  is  usually 
done.  For  exaeple,  the  code  stateaent  provided  by  Ada  seeas 
to  be  extreaely  inflexible.  There  seeas  to  be  no  way  to  use 
the  code  statement  with  a  particular  Ada  variable,  sc  code 
stateaents  cannot  be  used  for  aeaory-aapped  I/O.  (Although  a 
sequence  of  code  stateaents  to  output  any  register  could  be 
written,  there  seeas  to  be  no  way  to  ensure  that  what  is  to 
be  output  is  in  the  register.) 

The  use  of  address  specifications  in  interrupt  handling 
iaposes  a  problem,  due  to  the  reguireaent  that  the  expression 
in  an  address  specification  be  static.  This  liaitation 
precludes  dynaaically  changing  the  assignment  of  tasks  to' 
interrupts,  which  is  a  reguireaent  of  soae  systems.  This 
problem  is  discussed  at  length  elsewhere  in  this  report. 

Another  problem  is  caused  by  the  requireaent  for  static 
expressions  in  addresses.  A  package  that  exeaplifies  this 
restriction  is  called  "Interface  to  8254",  which  is  a 
general-purpose  interface  package  developed  to  support  an 
8254  LSI  interval  tiaer.  This  package  is  a  driver  for  the 
given  integrated  circuit.  All  communication  to  this 
peripheral  device  is  handled  by  the  package,  since  the 
address  of  the  chip  is  known  only  inside  this  package.  This 
works  acceptably  for  systeas  with  one  such  chip.  However,  in 
systeas  with  aultiple  interface  chips  of  the  sane  type,  there 
are  two  conflicting  solutions  to  the  address  specifications. 
Cne  solution  is  to  create  aultiple  copies  of  the  package. 
Except  for  the  package  naaes  and  hardware  addresses,  these 
packages  would  be  identical.  This  textual  duplication  will 
create  aaintenance  probleas.  A  second  possible  solution  is 
to  create  a  package  that  will  handle  one  or  nore  of  a  given 
chip.  This  would  probably  coaplicate  the  single-chip  package 
considerably,  since  it  seeas  the  aaount  of  code  would  be 
proportional  to  the  nuaber  of  chips.  For  example,  the 


reading  of  the  three  channels  of  the  8254  were  inplenented  in 
a  case  statement,  with  each  selection's  code  differing  only 
by  the  naaes  of  the  variables  defined  at  the  respective 
addresses. 

5. 6. 5. 2  separate  Coapilation 

this  problea  and  the  ones  that  follow  it  differ  froa  the 
previous  problea  in  that  they  are  not  probleas  with  language 
capabilities,  but  with  the  proper  application  of  these 
capabilities.  Hhile  separate  coapilation  nay  be  a  solution 
to  one  Ada  problea  (see  the  next  section) ,  its  use  adds 
coaplications  to  the  testing  and  aaintenance  porticns  of  the 
software  life  cycle.  One  of  these  coaplications  is  the  issue 
of  coapilation  dependency.  Cn  a  large  project,  it  nay  be 
iapossible  to  keep  track  of  the  coapilation  dependencies. 

The  separation  of  specification  and  body  into  separate 
coapilation  units  aay  reduce  the  aaount  of  coapilation 
dependency.  If  an  environaent  provides  a  tool  to 
autoaatically  keep  track  of  dependencies,  the  problea  of 
deciding  whether  a  particular  aodule  needs  to  be  reconpiled 
will  reaain,  even  when  the  tool  calls  for  it,  since  not  all 
changes  to  aodules  on  which  the  current  aodule  is  dependent 
will  actually  cause  changes  to  the  context  that  the  dependent 
aodule  can  "see".  Another  prcbleo  stews  froa  the  fact  that  a 
nodule  which  is  "separate"  inherits  the  context  at  the  point 
of  its  stub.  This  aeans  that  when  a  naintainer  looks  at  a 
aodule,  he  does  not  have  the  full  context  of  that  aodule  in 
front  of  hin.  It  nay  actually  be  in  a  different  file  froa 
the  one  he  is  editing.  In  fact,  since  the  containing  routine 
can  itself  be  "separate",  the  context  could  be  contained  in 
an  arbitrarily  large  nuaber  of  files.  This  certainly  could 
aake  aaintenance  nuch  acre  difficult. 

5. 6. 5. 3  »e5iiflg_af_Joa£iaes 

Ada  inherited  a  problea  froa  Pascal  which  wakes  the  reading 
of  prograas  auch  aore  difficult.  If  a  subprograa  contains 
nested  subprograas,  the  text  of  the  nested  routines  appears 
between  the  subprograa  specification  and  the  body  of  the 
subprograa,  separating  the  specification  (and  the  type  and 
object  declarations  of  the  prograa)  froa  the  body,  soaetiaes 
by  several  pages  in  large  systeas.  This  textual  separation 
can  aake  it  very  difficult  to  read  and  understand  the 
prograa.  Cne  way  to  solve  this  problea  is  to  use  stubs  and 
separately  coapile  the  nested  subprograas,  but  this  aay 
create  other  probleas.  (See  the  previous  section  for  a 
discussion  of  this  problea.) 

5. 6. 5. 4  issalLfilajiss 

The  "use"  clause  is  very  useful  to  the  prograaaer  during 
prograa  developaent.  It  can  save  hia  a  great  deal  of  trouble 
in  specifying  naaes  in  his  code.  However,  the  original 
prograaaer  has  an  extreae  advantage  over  any  aaintainer  when 
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it  coaes  to  reading  and  understanding  his  code,  since  be 
knows  where  his  naaes  caae  froa.  The  aaintenance  prograaner 
has  no  such  knowledge,  and  nay  experience  very  real  probleas 
in  resolving  the  origin  of  a  naae  in  the  code.  Be  has  only 
the  context  and  the  aeaning  (if  he  knows  it)  of  the  naae  to 
go  by  in  finding  out  its  genesis.  Because  of  this  problea, 
the  use  of  the  "use1*  clause  should  be  restricted  to  naaes 
which  coae  up  often  in  the  code.  Also,  it  would  be  nice  if  a 
tool  could  be  developed  which  would  add  full  gualif ication  to 
all  naaes  in  a  coapilation  unit.  In  alternate  tool  night 
provide  a  list  of  referenced  items  for  a  coapilation  unit, 
with  their  origins. 

5 . 6 . 5 . 5  MBiassii  taii2fl.i£ssif is aiisjis 

The  organization  of  the  Ida  declarative  part  with  respect  to 
representation  specifications  (rep  specs)  presents  a  problea 
in  readability,  ill  of  the  designers  on  this  project  felt 
that  the  required  separation  of  rep  specs  from  their  type 
declarations  was  difficult  to  read  and  would  present  a 
aaintenance  problea.  Declaration  of  a  type  to  be  used  in 
coaaunication  with  a  hardware  device  should  appear 
iaaediately  as  needed,  not  in  an  apparently  unrelated  area  of 
the  text  as  is  reguired  by  the  language.  One  proposed 
solution  would  be  to  declare  the  types  again  as  a  coament  in 
the  rep  spec  area  of  the  declarative  part.  Although  easier 
to  read,  a  docuaentation  problem  will  arise  in  keeping  the 
consent  declarations  up  to  date  when  the  real  declarations 
change. 

s. 6. s. 6 

This  aechanisn  is  very  versatile;  however,  when  the  objective 
of  inter-task  coaaunication  is  to  pass  data  without  actually 
halting  either  task  to  wait  for  the  other,  there  very  quickly 
arises  a  proliferation  of  tasks  to  act  as  buffers  and  handle 
the  passing  of  the  data.  This  condition  will  vary  with  the 
particular  application  involved  but  seeas  very  likely  to 
occur  in  real  tine  eabedded  applications. 

5. 6. s.7  ugSags-Siis 

The  packages  of  the  project  have  tended  to-  fcecone  quite 
large.  Some  are  too  large;  for  exanple,  PHYSICAL., PC BT  is 
nearly  forty  pages  long  (in  sixty-six  lines  per  page  format) . 
This  size  has  several  drawbacks. 

One  hindrance  is  the  difficulty  of  editing  a  file.  The 
aaount  of  editing  of  a  package  is  proportional  tc  its  size; 
however,  only  one  person  can  be  working  with  a  given  file  at 
once.  This  causes  probleas  if  the  package  is  being  coded  by 
several  people.  Also,  one  aust  ensure,  before  accessing  a 
file,  that  a  person  on  another  terminal  is  not  currently 
nodifying  that  same  file.  Furtheraore,  files  with  hundreds. 


or  even  thousands,  of  lines  are  difficult  to  edit  since  the 
desired  section  is  acre  difficult  to  locate. 
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6 .  Conclusion 

The  Ada  Capability  study  has  been  a  success  and  has 
demonstrated  that  Ada  can  be  used  effectively  in  the 
definition,  design,  and  programing  of  a  large  scale  digital 
systea.  In  a  span  of  twelve  months,  a  methodology  was 
developed,  personnel  were  trained,  systea  requirements  were 
defined,  a  design  was  accomplished ,  and  a  module  of  the 
systea  was  coded.  Since  an  Ada  coapiler  and  run  tiae  support 
package  are  not  yet  available,  it  was  not  possible  to  execute 
any  of  the  iapleaented  code.  It  is  recognized  that  certain 
embedded  real  tiae  applications  aay  present  Ada 
iapleaentation  problems  heretofore  not  realized,  particularly 
in  the  area  of  hardware  interfacing. 

A  case  study  such  as  this  is  a  good  beginning,  though  it  is 
only  the  beginning.  Continuing  research  in  methodology 
development  and  in  the  use  of  Ada  is  required  with  the 
development  of  coapilers  and  an  Ada  environment. 
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